1. Field of the Invention
The invention relates to the field of software development environments, and in particular, to the management of name consistency for objects in isolated file system name spaces.
2. Art Background
Traditional software development environments manage two types of objects, files and directories, in a hierarchical file system. Directories are known as container objects which contain files and other directories; they form a hierarchical file system name space (FSNS). Every object has both a contents and name attribute. Object names are unique in that no two objects may occupy the same name in a FSNS at the same time,. To rename an object is to change the name associated with that object in a FSNS. Both files and directories can be renamed, and renames which have been executed in one isolated FSNS can be propagated to another distinct but related FSNS automatically. Since an arbitrary object rename can be propagated from one FSNS to another FSNS, it is desirable to apply only those renames from the first FSNS to the second which are relevant to the object, regardless of other renames of other objects in the first FSNS.
Renames are propagated from one FSNS to another as follows: A time ordered list or renames was maintained on a per-FSNS basis. For each rename, a record of the unique id (identification) of the object, the time of the rename, and the old and new names of the object was made, respectively. To propagate an object from the local FSNS to a remote FSNS, both the contents and the name are "copied" from the local FSNS to the remote FSNS. To "copy" the name, all of the renames recorded for that object's unique id in the local FSNS's rename listed are applied to that of the object in the remote FSNS, thereby translating the name of the object in the remote FSNS to that of the local. The format of a rename list is: Rename ID) Old Name.fwdarw.New Name (Object ID. ) For example, the following renames are executed in the local FSNS:
a) A.fwdarw.B (1) PA1 b) B.fwdarw.C (1) PA1 a) Y.fwdarw.Z (1) PA1 b) X.fwdarw.Y (2) PA1 a) D1/Y.fwdarw.D1/Z (2) PA1 b) D1/.fwdarw.D2/ (1) PA1 c) D2/A.fwdarw.D2/B (3)
When object (1) is propagated from the local to the remote FSNS, renames a) and b) are applied to object 1 in the remote FSNS, in that order. The contents of object 1 are then copied from the local FSNS to the remote FSNS. Release 1.0 of the Network Software Environment (NSE) from Sun Microsystems, Inc., of Mountian View, Calif. propagated object renames in this fashion.
The prior art approach had several shortcomings. In the first two examples, there are initially two identical FSNS's containing the same objects with the same names. The "clearance" problem of renaming an object occurs because the final name of an object undergoing a rename must be available, i.e. not occupied by some other object. For example, if a local FSNS has two files named X and Y, a rename of Y and Z, respectively, must be executed in the following order.
The local FSNS now has two files, named Y and Z. Note that rename a) had to be executed before rename b) in order to make available (or "clear") the name Y in the FSNS. Rename a) is considered a "clearance" rename. If object 2 named Y, Y(2), (originally X(2)) is propagated to the remote FSNS, then Y(2)'s rename b) should be applied to the remote FSNS. However, the remote FSNS still has files X(2) and Y(1), and applying rename b) will collide with Y(1), and the propagation will fail.
Directory renames present two problems. First, if an object rename is propagated to the remote FSNS before the remote FSNS has received the rename for the directory containing the object, that object rename fails because the object rename refers to a directory name not yet defined in the remote FSNS. Second, once a directory rename has been applied in the remote FSNS, renames of other objects contained in the renamed directory may fail when applied in the remote FSNS because they refer to a directory by its original name, depending on whether or not the renames were executed before or after the directory rename in the local FSNS. For example:
Originally there were two files D1/Y and D1/A in the local FSNS. This sequence of renames results in D2/Z and D2/B in the local FSNS. If D2/B is propagated first, then its rename c) will fail when applied in the remote FSNS because it has not yet been renamed D2 in the remote FSNS. In a second scenario, assume that renames b) and c) were successively propagated to the remote FSNS. In order to propagate object (2) to the remote FSNS, the rename a) would have to be applied in the remote FSNS. But rename a) would fail because it refers to directory (1) by is original name D1, and the remote FSNS has renamed it D2.
The next two problems also involve the propagation of objects from one FSNS to another. But in these examples the local and remote FSNS's, though similar, initially differ in the number and/or names of the objects.
A rename "conflict" occurs when the same object is renamed in different FSNS's. If the same object is renamed in the local and remote FSNS, then propagation of the object from the local to the remote FSNS will fail because the object in the remote FSNS does not have the original name of the object in local FSNS. For example:
______________________________________ Local FSNS Remote FSNS ______________________________________ a) A .fwdarw. Y (1) b) A .fwdarw. Z (1) ______________________________________
When propagating object (1) to the remote FSNS, rename a) will fail because in the remote FSNS object (1) is not named "A".
A rename "collision" occurs when the object is propagated from the local to the remote FSNS when an object in the local FSNS is renamed to a name occupied by another object in the remote FSNS and this second object does not exist in the local FSNS. For example, object A(1) exists in both the local and remote FSNS, and object B(2) exists only in the remote FSNS and is unknown in the local FSNS. The following rename is executed;
______________________________________ Local FSNS Remote FSNS ______________________________________ a) A .fwdarw. B (1) ______________________________________
When object (1) is propagated from the local to the remote FSNS, rename a) will fail because it will "collide" with object B(2) in the remote FSNS.